Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000019_owner-urn-ietf _Fri Aug 16 18:13:35 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA21285 for urn-ietf-out; Fri, 16 Aug 1996 18:13:35 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA21280 for <[e-mail]>; Fri, 16 Aug 1996 18:13:31 -0400
Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA27685  (mail destined for [e-mail]); Fri, 16 Aug 96 18:13:24 -0400
Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa27372;
          16 Aug 96 18:12 EDT
Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM)
    id AA04505; Fri, 16 Aug 1996 18:12:45 -0400
Date: Fri, 16 Aug 1996 18:12:45 -0400
Message-Id: <[e-mail]>
From: Lewis Girod <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Ron
    Daniel on Thu, 15 Aug 1996 08:29:34 -0600)
Subject: Re: [URN] nasty rewriting rules
Sender: [e-mail]
Precedence: bulk
Reply-To: Lewis Girod <[e-mail]>
Errors-To: [e-mail]

   on Date: Thu, 15 Aug 1996 08:29:34 -0600 Ron Daniel wrote:

   Thus spoke Lewis Girod (at least at 03:54 PM 8/13/96 -0400):

   >Fair enough, although it is important to have agreement as to what
   >flavor of regexps are being used.  The original plan was to just
   >execute sed, which solves both issues on UNIX platforms, but requires
   >a little more work otherwise.

   Um, no, that was not the plan. The plan was to use regexp libraries, the
   syntax of the regexps was "sed-style" rather than "perl-style" because
   we believe that sed-style is actually the version most regexp libraries
   support.

OK.

   >There is some suggestion in the framework document that there be a set
   >of requirements of new name schemes

   Well, I thought that those requirements were going to be things like
   no reassigning of naming authorities, making sure that any naming
   authorities in a naming scheme require any sub-naming authorities to follow
   rules at lesat as restrictive as the ones they operate under, ...

   So, these really are requirements on naming schemes and the operations
   behing them. Such requiremnts can't be tested by validating the syntax of
   a URN - useful thought that might be.

    [...]

   >Humans are supposed to use the simple user-friendly
   >syntax that compiles into the terse form.  With decent management
   >software the underlying terse form should be transparent to the
   >administrator -- in fact, if we can assume that everyone is using a
   >compiler it might be a good idea to make the terse form even more
   >compact.

   Those are pretty strong assumptions Lewis. Furthermore, this software
   also has to decompile the terse form into the friendly form so that
   people can debug existing records. This sort of friendly software
   rarely gets written and maintained.

I think the question of what sorts of requirements are desirable has a
significant impact on the likelihood that new name schemes would be
servable by future systems.  I had inferred some stronger requirements
than prevention of name reassignment from the framework document:

  ----------------------------------------
  Namespace Identifier Requirements and
  Administration
  ----------------------------------------

  Some set of criteria must be established to govern what can and cannot
  be used as a (top-level) namespace (NID assignment).  This can include:

    . demonstration of an established namespace management system
      (including an overview of mechanisms for preventing the
      duplication/reassignation of name identifiers.  These mechanisms
      are particular to the individual namespaces).
    . multi-organization participation in the naming system
    . rules on how names are assigned, name assignment authority
      delegation
    . provision of escape clause

                  (from draft-daigle-urnframework-00.txt)

For example, consider the third point; I interpret this as requiring a
specification of the ways in which collections can be delegated within
the syntax of the URNs.  The only way I can see to make this work is
to somehow embed the rules of delegation into the URN syntax so that
they can be verified syntactically.  As I see it, the primary function
of my proposal is that the translation step and the limited nature of
the rules after that enforces a delegation structure based on a
definition at the top level.  At the top level the delegation
hierarchy is ordered canonically and fixed; below that it cannot be
processed out of order except by escaping to a separate resolution
mechanism.  An interesting property of my proposal is that there are
no real syntactic requirements beyond those needed to re-order the
URN.

As you point out, this particular effect cannot be obtained using the
regexp rules, even with an initial syntactic check at the beginning.

I interpreted point one to imply something concrete in the way of a
``management system''.  For example, demonstration of administrative
software that name assignment authorities would be given to maintain
the databases is a requirement I had in mind.  That was why I was
assuming that people would have a rule compiler (although it really is
not that hard to implement!).  A decompiler would be nice for
emergencies, but I was thinking that the rules would be kept in and
installed from the source format, so to debug things you would go back
to the source file.

Perhaps my interpretations are outside of the sense of the
requirements, or perhaps the requirements simply haven't been
specified clearly... in any case, I think we need to make sure that
the requirements that we do want are at least partially enforced in a
technical way by the system.  (We may need to figure out what they are
first?)  Because regexps allow a lot of flexibility downstream it is
hard to make requirements, and thus the potential exists for dowstream
administrators to make messes.

-lewis